The IP Multimedia Subsystem (IMS) is a Next Generation Networking (NGN) architecture for telecom operators, standardised by the Third Generation Partnership Project (3GPP), which can provide multimedia services to mobile and fixed terminals. IMS uses SIP (Session Initiation Protocol) based signalling and Internet Protocol (IP) connectivity.
A number of CSCF (Call Session Control Function) entities are used to establish a session within the IMS network and process SIP signalling packets. The CSCF entities are the Proxy-CSCF (P-CSCF), Interrogating-CSCF (I-CSCF) and Serving-CSCF (S-CSCF). FIG. 1 shows part of an IMS network which includes the S-CSCF. The S-CSCF is responsible for handling registration processes, making routing decisions and maintaining session states.
Application servers (AS) within an IMS network can host and execute applications which provide services. An Application Server interfaces with the S-CSCF via an IMS Service Control (ISC) interface which uses SIP signalling. Services can include call related services such as Call waiting, Call holding, Call forwarding, Call transfer, Call blocking services. Applications can also provide services such as notifying a user of particular information, such as stock prices or football results. Applications can be provided by the operator of the IMS network, with the application being hosted and executed by a SIP Application Server within the IMS network.
Alternatively, an application can be provided by a third party service provider external to the IMS network, as shown in FIG. 1. An Application Server 30 within the IMS network, called an Open Service Architecture Service Capability Server (OSA SCS), can provide IMS network resources to implement the external service. The S-CSCF communicates with the OSA-SCS over an IMS Service Control (ISM), SIP-based, signalling interface 24. An OSA gateway 14 acts as an intermediary between the OSA SCS 30 and an Application 42 in the IT environment 40. Alternatively, the OSA gateway 14 can interface directly with the S-CSCF 22. An Application can interface directly with the OSA Gateway 14 via an OSA Application Programming Interface (OSA API), which typically uses Parlay over CORBA. Application 41 interfaces with OSA Gateway 14 in this manner. For Applications which use XML, a Parlay-X interface is used and a Parlay-X gateway 16 is required. Application 42 uses a Parlay-X interface to communicate with the Parlay-X gateway 16. The Parlay-X gateway uses a Parlay interface to communicate with the OSA gateway 14. IT-based applications or web-based services typically exchange data in an XML format, and so the arrangement of gateways shown in FIG. 1 is usually required. It can be seen that, with the current architecture, two gateway elements are required whenever an application 42 which uses an XML-based messaging format is connected to the IMS network. This considerably increases the complexity of implementing applications provided by third parties.
The present invention seeks to provide an alternative way of implementing applications in an IMS network.